With the increasing popularity of object-oriented programming languages and systems, the development of distributed object systems has presented new challenges regarding the creation, referencing, invocation and use in general of the objects within these distributed systems. It has become common to provide remote procedure call (RPC) facilities that extend the semantics of local procedure calls to these distributed object systems. This often takes the form of remote object invocation. However, rather than there being a single set of obvious semantics for all remote objects, there appears to be a wide range of possible object semantics, often reflecting different application requirements. For example, there are distributed object systems that include integrated support for the features of replication, atomic transactions, object migration, and persistence. But there are also distributed object systems that provide only minimal features and instead concentrate on high performance.
One possible reaction to this diversity is to attempt to design a single distributed object system for remote objects that includes all possible features. Unfortunately, the list of possible features is continually expanding, and not all features are necessarily compatible. For example, a high performance system may not want its objects to include support for the features of persistence or atomicity. Moreover, there are often a variety of different ways of implementing a given set of semantics. Having a single system prevents applications from exploiting new and improved features that may better reflect their real needs. For example, in order to increase reliability, it may be desired to support the feature of object replication. However, it would not be desirable to have client application code doing extra work simply to talk to replicated objects, so it would be preferable to support replication "underneath the covers", as part of the object's invocation mechanism. But there are many different ways of implementing replication, and it is undesirable to build in support for some particular set of features while implicitly rejecting others.
There are a wide variety of features or object mechanisms that a distributed object system might provide. By way of example, a distributed object system may provide such features such as replication, atomic transactions, object migration, persistence, naming, event notification, relationships, server activation, clean shutdown, transactions, security, and enablement of filters (compression, encryption, tracing, debugging, etc.). These features may also be called services and may be provided by an Object Services module as part of a distributed object system. Past distributed object systems have suffered in that they were unable to provide a flexible subset of these features for different applications, much less for different objects within an application. Past systems only provided a fixed set of these features.
This deficiency may be addressed through the notion of a subcontract. Subcontracts and their use are described in the above-referenced patent application Ser. No. 08/554,794. The notion of a subcontract is also described in "Subcontract: A Flexible Base for Distributed Programming" by G. Hamilton, M. Powell and J. Mitchell, published by Sun Microsystems Laboratories, Inc., 1993. Subcontracts and their associated functionality may be implemented in many different ways.
Through the use of subcontracts, an application may specify which of the various above features (among others) it wishes to take advantage of, or may even specify different groups of features that may be used by different objects within the application. A group or a permutation of these features is termed a subcontract. Thus, each object within an application may utilize a particular subcontract (or group of features). A group of desired features is also termed a desired a quality of service. And these desired features may be represented in a quality of service list. A subcontract, then, delivers a particular quality of service within a distributed object application. An object may have one subcontract associated with it at a given time. Subcontracts are separate from object interfaces and object implementations. Thus, it is easy for object implementers to either select and use an existing subcontract, or to implement a new subcontract. Correspondingly, application level programmers need not be aware of the specific subcontracts that are being used for particular objects. A subcontract associated with an object allows the business of implementing an object to be separate from the business of implementing the object mechanisms or features provided by the system.
One of the reasons that subcontracts are effective is because they separate out the business of implementing objects from implementing object mechanisms. The availability of subcontracts enable object implementers to choose from a range of different object mechanisms (or features) without requiring that every object implementer must become familiar with the details of the object implementation machinery. The set of features that subcontracts provide are the right levers for obtaining control within a distributed environment. By design, all of the key actions taken on remote objects will involve the object's subcontract in one way or another. By way of example, actions such as object creation, object reference creation and method invocation involve the object's subcontract. Subcontracts provide an effective way for plugging in different policies for different objects and are successful in reducing the functionality that must be provided by the base system.
However, conventional distributed object system have not utilized the functionality of subcontracts and are not well adapted to integrating subcontracts. The common object request broker architecture (CORBA), defines the notion of an object adaptor. Among other tasks, an object adaptor creates servant objects and dispatches requests to a server. Object adaptors provide a limited set of choices about the server-side object mechanisms. However, most object adaptors are supplied as part of the basic object machinery, and it is not realistically possible for application writers to implement new object adaptors, or for the object machinery to discover and install new object adaptors at run time. For example, the Basic Object Adaptor (BOA) defined under CORBA is very limited in that it only provides a fixed set of features. As discussed above, it is less than desirable that an object only be provided with a fixed set of features. And even if all features are supplied, this comes at the expense of performance, and vice-versa. However, one object in a particular application may only need to utilize a limited set of features, as contrasted with a different object in the same application that needs a different set of features. Thus, prior art object adaptors may unnecessarily burden objects with extra features resulting in high overhead and increased use of CPU time.
Accordingly, the creation of a mechanism that is able to implement some of the traditional object adaptor functions, while at the same time, being capable of taking advantage of the use of subcontracts would be desirable. Such an object adaptor would overcome the shortcomings of fixed Object Adaptors in that it would permit different objects within a distributed system to take advantages of some, but not necessarily all of the features provided by the distributed object system.